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SYSTEM AND METHOD FOR IDENTIFYING AND 
CHARGING FOR PRINT REQUESTS 

BACKGROUND 

5 [0001] Public areas may include computers and printers that allow users to print 

desired files, images, or other objects. When a print job is submitted to a public 
printer, the print job is typically printed automatically, for example, based on the 
order it was received. The user can then retrieve the printed job from the printer. 
However, printed jobs may remain in the open and accessible for other people to see 
10 and/or take. In some environments, a printer may be maintained behind a counter and 

the user is required to pay for a print job before the printed job can be retrieved from 
the personnel operating the printer. However, print jobs may be printed and 
abandoned without receiving payment, thereby wasting the resources of the printer. 

1 5 BRIEF DESCRIPTION OF THE DRAWINGS 

[0002] The accompanying drawings, which are incorporated in and constitute a 
part of the specification, illustrate various example systems, methods, and so on that 
illustrate various example embodiments of aspects of the invention. It will be 
appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or 
20 other shapes) in the figures represent one example of the boundaries. One of ordinary 

skill in the art will appreciate that one element may be designed as multiple elements 
or that multiple elements may be designed as one element. An element shown as an 
internal component of another element may be implemented as an external component 
and vice versa. Furthermore, elements may not be drawn to scale. 

25 [0003] Figure 1 illustrates an example print request processing system. 

[0004] Figure 2 illustrates an example methodology associated with delaying a 
print request until physically claimed. 

[0005] Figure 3 illustrates an example image forming device for receiving and 
claiming print requests. 
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[0006] Figure 4 illustrates an example methodology associated with claiming a 
print request. 

[0007] Figure 5 illustrates another example print request processing system that 
identifies and charges for print requests. 

5 [0008] Figure 6 illustrates another example image forming device including a 

print request processing system. 

[0009] Figure 7 illustrates an example graphical user interface. 
[0010] Figure 8 illustrates an example print driver. 

1 0 DETAILED DESCRIPTION 

[0011] The following includes definitions of selected terms employed herein. The 
definitions include various examples and/or forms of components that fall within the 
scope of a term and that may be used for implementation. The examples are not 
intended to be limiting. Both singular and plural forms of terms may be within the 
15 definitions. 

[0012] "Computer-readable medium", as used herein, refers to a medium that 
participates in directly or indirectly providing signals, instructions and/or data. A 
computer-readable medium may take forms, including, but not limited to, non-volatile 
media, volatile media, and transmission media. Non-volatile media may include, for 

20 example, optical or magnetic disks and so on. Volatile media may include, for 

example, optical or magnetic disks, dynamic memory and the like. Transmission 
media may include coaxial cables, copper wire, fiber optic cables, and the like. 
Transmission media can also take the form of electromagnetic radiation, like those 
generated during radio-wave and infra-red data communications, or take the form of 

25 one or more groups of signals. Common forms of a computer-readable medium 

include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic 
tape, other magnetic medium, a CD-ROM, other optical medium, punch cards, paper 
tape, other physical medium with patterns of holes, a RAM, a ROM, an EPROM, a 
FLASH-EPROM, or other memory chip or card, a memory stick, a carrier 
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wave/pulse, and other media from which a computer, a processor or other electronic 
device can read. Signals used to propagate instructions or other software over a 
network, like the Internet, can be considered a "computer-readable medium." 

[0013] "Data store", as used herein, refers to a physical and/or logical entity that 
5 can store data. A data store may be one or more of, for example, a database, a table, a 

file, a list, a queue, a heap, a memory, a register, and so on. A data store may reside 
in one logical and/or physical entity and/or may be distributed between two or more 
logical and/or physical entities. 

[0014] "Logic", as used herein, includes but is not limited to hardware, firmware, 
10 software and/or combinations of each to perform a function(s) or an action(s), and/or 

to cause a function or action from another component. For example, based on a 
desired application or needs, logic may include a software controlled microprocessor, 
discrete logic like an application specific integrated circuit (ASIC), a programmed 
logic device, a memory device containing instructions, or the like. Logic may also be 
15 fully embodied as software. Where multiple logical logics are described, it may be 

possible to incorporate the multiple logical logics into one physical logic. Similarly, 
where a single logical logic is described, it may be possible to distribute that single 
logical logic between multiple physical logics. 

[0015] An "operable connection", or a connection by which entities are "operably 
20 connected", is one in which signals, physical communication flow, and/or logical 

communication flow may be sent and/or received. Typically, an operable connection 
includes a physical interface, an electrical interface, and/or a data interface, but it is to 
be noted that an operable connection may include differing combinations of these or 
other types of connections sufficient to allow operable control. For example, two 
25 entities can be operably connected by being able to communicate signals to each other 

directly or through one or more intermediate entities like a processor, an operating 
system, a logic device, software, or other entity. Logical and/or physical 
communication channels can be used to create an operable connection. 

[0016] "Signal", as used herein, includes but is not limited to one or more 
30 electrical or optical signals, analog or digital signals, data, one or more computer or 
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processor instructions, messages, a bit or bit stream, or other means that can be 
received, transmitted and/or detected. 

[0017] "Software", as used herein, includes but is not limited to, one or more 
computer or processor instructions that can be read, interpreted, compiled, and/or 
5 executed and that cause a computer, processor, or other electronic device to perform 

functions, actions and/or behave in a desired manner. The instructions may be 
embodied in various forms like routines, algorithms, modules, methods, threads, 
and/or programs including separate applications or code from dynamically linked 
libraries. Software may also be implemented in a variety of executable and/or 

10 loadable forms including, but not limited to, a stand-alone program, a function call 

(local and/or remote), a servelet, an applet, instructions stored in a memory, part of an 
operating system or other types of executable instructions. It will be appreciated by 
one of ordinary skill in the art that the form of software may be dependent on, for 
example, requirements of a desired application, the environment in which it runs, 

15 and/or the desires of a designer/programmer or the like. It will also be appreciated 

that computer-readable and/or executable instructions can be located in one logic 
and/or distributed between two or more communicating, co-operating, and/or parallel 
processing logics and thus can be loaded and/or executed in serial, parallel, massively 
parallel and other manners. 

20 [0018] Suitable software for implementing the various components of the 

example systems and methods described herein include programming languages and 
tools like Java, Pascal, C#, C++, C, CGI, Perl, SQL, APIs, SDKs, assembly, 
firmware, microcode, and/or other languages and tools. Software, whether an entire 
system or a component of a system, may be embodied as an article of manufacture 

25 and maintained as part of a computer-readable medium as defined previously. 

Another form of the software may include signals that transmit program code of the 
software to a recipient over a network or other communication medium. Thus in one 
example, a computer-readable medium has a form of signals that represent the 
software/firmware as it is downloaded from a web server to a user. In another 

30 example, the computer-readable medium has a form of the software/firmware as it is 

maintained on the web server. Other forms may also be used. It will be appreciated 
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that components described herein may be implemented as separate components or 
may be combined together. 

[0019] "User", as used herein, includes but is not limited to one or more persons, 
software, computers or other devices, or combinations of these. 

5 [0020] Some portions of the detailed descriptions that follow may be presented in 

terms of algorithms and symbolic representations of operations on data bits within a 
memory. These algorithmic descriptions and representations are the means used by 
those skilled in the art to convey the substance of their work to others. An algorithm 
is here, and generally, conceived to be a sequence of operations that produce a result. 
10 The operations may include physical manipulations of physical quantities. Usually, 

though not necessarily, the physical quantities take the form of electrical or magnetic 
signals capable of being stored, transferred, combined, compared, and otherwise 
manipulated in a logic and the like. 

[0021] It has proven convenient at times, principally for reasons of common 
15 usage, to refer to these signals as bits, values, elements, instructions, symbols, 

characters, terms, numbers, or the like. It should be borne in mind, however, that 
these and similar terms are to be associated with the appropriate physical quantities 
and are merely convenient labels applied to these quantities. Unless specifically 
stated otherwise, it is appreciated that throughout the description, terms like 
20 processing, computing, calculating, determining, displaying, or the like, refer to 

actions and processes of a computer system, logic, processor, or similar electronic 
device that manipulates and transforms data represented as physical (electronic) 
quantities. 

[0022] Described herein are example systems, methods, computer-readable 
25 media, print drivers, graphical user interfaces, and other embodiments associated with 

identifying and/or charging for print jobs. In one example system, print jobs/requests 
can be parked or otherwise delayed in an image forming device until they are claimed 
by their owner. To have a print request actually printed, a user can provide a credit 
card or other identification device to the image forming device in order to claim the 
30 print request. Providing the card indicates to the system that the user is physically 
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present and is requesting to retrieve their print request. The data from the credit card 
can be used to identify delayed print requests that belong to the user and may also be 
used to pay for the print request by charging the credit card. The credit card data, for 
example, such as the user's name or last four digits of their card number, can be used 
5 to match identity information associated with each print request. 

[0023] For image forming devices that are in a public venue, print requests are not 
printed until the owner physically claims the print request by swiping his/her credit 
card at the printer, or by providing other types of identification information. This may 
assist with security issues where printed documents are not printed for anyone to see 

10 or take, but rather, are printed when the owner is physically in the presence of the 

image forming device and is ready to retrieve his/her printed job. Additionally, by 
using a credit card or other card with charge account information, the image forming 
device can charge for the services of processing the print request by charging the 
credit card. Thus, in one example, identifying and charging for print requests can be 

15 performed in response to one action from a user such as a single data input (e.g. 

single swipe of a credit card). The single data input serves as both identifying 
information and charging information. 

[0024] Illustrated in Figure 1 is one example of a print request processing system 
100 that can be configured to hold print requests in an image forming device until a 
20 print request is claimed or otherwise retrieved by a user that sent the print request. 

The print request processing system 100 can be local to an image forming device, can 
be part of a computer or print server in communication with the image forming 
device, or can be embodied in a different desired manner. The system 100 can be 
configured using any type of desired logic. 

25 [0025] A print delay logic 105 can be configured to handle incoming print 

requests 110. The print requests 110 are initially held up and may be maintained in a 
pending state as delayed print requests 115. For example, the delayed print requests 
115 can be held in a queue until they are claimed or retrieved by their owner. In that 
regard, an input device 120 can be provided that is configured to receive claim request 

30 data 125 from a user. The claim request data 125 can be any type of identification 

information such as a user's name and/or other identification information that can be 
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used to associate the user to his/her delayed print request(s) 115. It is presumed that 
the delayed print request(s) 115 includes corresponding identification information that 
allows for the information to be compared with the claim request data 125. The 
configuration of the delayed print request(s) 115 will be described in greater detail 
5 below. 

[0026] In one example, the input device 120 can be a magnetic card reader and 
the claim request data 125 can be the information obtained from a card read by the 
input device 120. Once the claim request data 125 is received, an identification logic 
130 can be configured to match the claim request data 125 with identification data 
10 associated with each of the delayed print requests 115. Thus, the identification logic 

130 can be configured to identify one or more print requests for which the user that 
inputted the claim request data 125 is an owner. The pending print request(s) 
belonging to the user are identified in Figure 1 as claimed print request(s) 135. 

[0027] It will be appreciated that the claim request data 125 may include more 
15 information than is necessary in order to identify a matching print request. For 

example, a credit card swiped in the input device 120 may provide a set of data but, 
the identification logic 130 may only use selected portions or sub-sets of the data in 
order to identify and associate with a matching print request. If a match is found, the 
identification logic 130 can be configured to cause the identified one or more delayed 
20 print requests to be processed by the image forming device into a printed job. In this 

manner, print requests can be delayed until physically claimed by a user so that 
documents are not printed until the user is physically present to retrieve the printed 
documents. It will be appreciated that when each of the print requests 110 are 
generated, owner identification is received from the user and associated with each 
25 print request so that the owner information can be used to match against the claim 

request data 125. Generating print requests will be described in greater detail below. 

[0028] With further reference to Figure 1, the input device 120 can, in one 
example, be a card reader or other information reading device configured to read 
identification data from an identification device provided by the user. The 
30 identification data, which becomes part of the claim request data 125, can also include 

charge account information. A payment logic (not shown) may also be provided that 
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is configured to charge an account based on the charge account information. The 
identification device may be, for example, a credit card, a debit card, a student 
identification card, an employee identification card, an electronic device including 
logic, a computer-readable medium, or the like. The charge account information may 
5 be used to identify an account that can be charged based on the charge account 

information. 

[0029] In another example, the input device 120 can include a key pad configured 
to allow a user to input an identification code such as a password, that can become 
part of the claim request data 125. The key pad can be used in combination with the 

10 card reader. Each delayed print request 115 can include owner identification that 

allows the identification logic 130 to compare the identification code (provided by the 
user) to the owner identification of each print request 115 to determine a match. If 
there is a match, the delayed print request 115 then becomes a claimed print request(s) 
135 that can be sent for processing into a printed output. It will be appreciated that a 

15 data store can be used to maintain the delayed print requests 115 in any desired 

computer-readable medium, like a memory, within an image forming device. 

[0030] Illustrated in Figure 2 is an example methodology 200 associated with 
processing print requests transmitted to an image forming device. While for purposes 
of simplicity of explanation, the illustrated methodologies are shown and described as 

20 a series of blocks, it is to be appreciated that the methodologies are not limited by the 

order of the blocks, as some blocks can occur in different orders and/or concurrently 
with other blocks from that shown and described. Moreover, less or more than all the 
illustrated blocks may be required to implement an example methodology. 
Furthermore, additional and/or alternative methodologies can employ additional, not 

25 illustrated blocks. 

[0031] In the flow diagrams, blocks denote "processing blocks" that may be 
implemented with logic. A flow diagram does not depict syntax for any particular 
programming language, methodology, or style (e.g., procedural, object-oriented). 
Rather, a flow diagram illustrates functional information one skilled in the art may 
30 employ to develop logic to perform the illustrated processing. It will be appreciated 

that in some examples, program elements like temporary variables, routine loops, and 
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so on are not shown. It will be further appreciated that electronic and software 
applications may involve dynamic and flexible processes so that the illustrated blocks 
can be performed in other sequences that are different from those shown and/or that 
blocks may be combined or separated into multiple components. It will be 
5 appreciated that the processes may be implemented using various programming 

approaches like machine language, firmware, procedural, object oriented and/or 
artificial intelligence techniques. The various actions illustrated and/or described 
herein can occur in serial, but also various actions could occur substantially in 
parallel. 

10 [0032] With reference to Figure 2, when a print request is received, the print 

request can be maintained as a pending print request until physically claimed by a 
user (Block 205). By holding print requests, theft of printed documents and/or 
viewing of confidential documents by unauthorized users may be prevented or at least 
reduced. In order to initiate printing of a print request, a user/owner would be 

15 required to be physically in the presence or vicinity of the image forming device and 

identify himself/herself to the image forming device. The identification can be 
performed by, for example, inputting or otherwise providing identification data, 
which will also be referred to herein as claim data. 

[0033] In response to receiving the physically inputted claim data, the process can 
20 determine which pending print requests belong to the user (Block 210). If the 

inputted claim data matches with a pending print request, the print request becomes a 
claimed print request and is selected for processing into a printed output (Block 215). 
Optionally, if one or more print requests are validly claimed, the claimed print 
requests can be displayed to the user and the user may be allowed to selectively 
25 initiate printing of the print request that belongs to them. 

[0034] It will be appreciated that the methodology 200 and the other 
methodologies described herein can be embodied as processor-executable instructions 
provided by a computer-readable medium. For example, processor-executable 
instructions can be provided that are configured to cause an image forming device, a 
30 computing device, or other logic to process print requests as described herein. The 

processing may include receiving a print request that includes an associated user 
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identification; delaying the processing of the print request in the image forming 
device until the request is claimed by a user; and in response to receiving claim data 
from a user in the presence of the image forming device (e.g. physically inputting 
identification data), and the claim data can be compared with the user identification 
associated with the delayed print request. The print request can then be processed if 
the user identification matches the claim data. 

[0035] The process 200 may also include maintaining the received print requests 
in a queue where the print requests are received from one or more sources and/or one 
or more users. Additionally, the process may be configured so that a user account can 
be automatically charged for the claimed print request based on the claim data 
received. As described previously, the claim data may include credit card or other 
charge account information that can be used to charge for the printing services of the 
image forming device. Optionally, the process may also perform a pre-authorization 
on a user account identified by the claim data prior to processing the print request. 
For example, a verification can be performed to validate that the user account is valid 
and has sufficient funds or charge limits available to cover the costs of printing the 
claimed print request(s). 

[0036] Illustrated in Figure 3 is an example of an image forming device 300 
configured to delay processing of print requests until retrieved by an owner of the 
print request. The image forming device 300 can be configured to receive print 
requests from one or more clients 305 such as computers, print servers, portable 
devices, or other device or service that can generate and transmit a print request. The 
client 305 can be in communication with the image forming device 300 by a variety 
of means such as direct connection, wireless connection, network connection, a 
connection through a print server, or other desired communication configuration and 
using any desired protocol. 

[0037] The client 305 can include a print driver 310 configured to process print 
requests for a user. For example, the print driver 310 can include logic configured to 
generate a print request based on a selected data that is desired to be printed. The 
selected data can be, for example, a document, an image, a file, or other type of object 
that can be printed. The print driver 310 may also include logic configured to obtain, 

10 
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from the user, owner identification data to be embedded into the print request. For 
example, the print driver 310 may request a user's name, credit card information, 
other identification information, a password, and/or any combination of these. In the 
following example, it will be assumed that credit card information is used. The owner 
5 information (e.g. credit card information) can then combined or otherwise associated 

with the print request and transmitted to the image forming device 300. 

[0038] As print requests are received by the image forming device 300, the print 
requests are delayed or otherwise maintained in a pending state until physically 
claimed by the user, for example, by providing claim data to the image forming 

10 device 300. The claim data will be used to match against the owner identification 

data in the pending print requests to determine ownership. A card reader 315 can be 
connected to the image forming device 300 where the card reader 315 is configured to 
accept or receive claim data or other type of identification data from a user. For 
example, the card reader 315 can be a credit card reader where a user can swipe a 

15 credit card 320 and the credit card data is used as claim data by the image forming 

device 300. By detecting a swipe of the credit card, the image forming device 300 
can ensure that the user is physically present. 

[0039] The credit card data can then be used to compare with the owner 
identification data embedded in pending print requests to determine if there is a 

20 match. If a match is found, meaning that the user who swipes the credit card 320 is 

the same user that initiated the print request on the client 305, the claimed print 
request is then processed into a printed output 325. In this example, the owner 
identification data inputted into the print driver 310 would include, for example, the 
user's name, the user's credit card number, selected portions or sub-sets of the credit 

25 card number (e.g. the last four digits), or other selected data that would be contained 

on the credit card so that a match can be determined. In another example, the user 
who claims the print request may not be the same user that generated the print request 
but may be an authorized agent, a co-owner of the credit card, and the like. In another 
example configuration, the logic to perform above-described processing and the card 

30 reader 315 may be local to a print server (not shown) that is in communication with 

the image forming device 300. 
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[0040] Illustrated in Figure 4 is an example methodology 400 associated with 
identifying ownership of and charging for processing of print requests. In the 
example, it is assumed that print requests are being held in a pending state and have 
been preconfigured with identification data that will be used to identify the owner of 
5 each print request. The example will also be described with reference to a system that 

includes a credit card reader although other types of identification cards can be used 
that include identification of an account that may be charged. The process 400 can be 
triggered by the receipt of credit card data, for example, by reading a credit card that 
is swiped (Block 405). The credit card data can then be compared and matched with 

10 information associated with pending print requests (Block 410). For example, if the 

identification information associated with a print request includes the last four digits 
of a credit card, the last four digits of the inputted credit card data will be compared to 
determine if a match exists, thereby identifying ownership of the print request. If 
there is a match, the credit card can be charged for printing the print request(s) and the 

1 5 matched print request(s) can be processed into a hard copy (Block 415). 

[0041] The process may include charging a flat fee for printing services, 
dynamically determining the cost of each print request, or using other types of cost 
calculating algorithms. For example, a print request may indicate the number of 
pages included in the request. The cost can then be calculated based on the number of 
20 pages and charged to the credit card. The process may also include verifying that the 

credit card is valid and/or has appropriate funds or limits before charging the account. 
It will be further appreciated that the credit card can be other types of cards that allow 
for the charging of an account. 

[0042] Illustrated in Figure 5 is another example of a print request processing 
25 system 500 that is configured to process print requests 505 directed to an image 

forming device. The print request processing system 500 can be implemented in logic 
and can be implemented within or local to an image forming device, a computing 
device, a print server, or another desired component within an image processing 
system. As the print requests 505 are received, they can be held in a data store on a 
30 computer-readable medium as pending print requests or data store 510. Each print 

request may include owner information (e.g. an owner ID) associated with it such as a 
user's name, credit card number, password, other desired identification, and/or 



12 



Docket No. 200209495-1 



combination of these. The owner information can be attached to each print request in, 
for example, header information. The system 500 can be configured to analyze or 
otherwise parse each print request to identify, for example, a print request identifier 
and the owner identification. These identifiers and/or other data can be stored in a 
5 table 515 and/or memory that associates the print request ID and the owner ID 

together. 

[0043] As print requests 505 are received, a print delay logic 520 can be 
configured to delay the processing of each print request by placing the print request in 
the data store 510 until it is claimed by an owner of the print request. An input device 

10 525 such as a card reader can be provided and configured to read a credit card that is 

provided by a user who wishes to claim a pending print request. Optionally, a key 
pad can also be used to receive additional identification data that can be combined 
with credit card data, if desired. If successfully claimed, the print request can then be 
initiated for printing. The credit card data is one example of user data 530 that can be 

1 5 inputted into the input device 525 in order to claim a pending print request 510. 

[0044] When the user data 530 is received, this event indicates that a user is 
physically present and is attempting to claim a print request. In response, an 
identification logic 535 can be configured to identify which of the pending print 
requests 510 in the data store are owned by the user by comparing the user data 530 
20 (e.g. credit card data) with the owner information associated with the print requests, 

for example, the owner ID from the table 515. If a match is found, the associated 
pending print request can be selected for processing. 

[0045] Optionally, a payment logic 540 may also be provided that is configured to 
charge the credit card read by the input device 525 for the services performed by the 

25 image forming device. An imaging logic 545 can be configured to cause the image 

forming device to print the matched print request(s) identified by the identification 
logic 535. This may include, for example, sending the matched print request to an 
imaging mechanism to be printed into a hard copy. As another example, the print 
request processing system 500 may include a display (not shown) configured to 

30 display the matched print requests that were identified as owned by the user using a 

graphical user interface. 
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[0046] Illustrated in Figure 6 is another example of an image forming device 600 
that can include a print request processing system 605 that is configured like the 
system 100, the system 500, configured with combinations of these systems, or with 
similar components. The print request processing system 605 can be configured to 
5 delay the processing of print requests until physically claimed or retrieved by their 

owner. An imaging mechanism 610 can be included that is configured to generate a 
printed output on print media, in accordance with instructions and/or data from a print 
request. 

[0047] In one example, the print request processing system 605 can be operated 
10 using a chai service 615 that is configured to execute logic or instructions, 

communicate with network devices, and communicate with a card reader 620 or other 
type of input device that can receive data from a user. The image forming device 600 
can operate to delay processing of print requests until claimed by a user in one or 
more of the ways previously described. In another example, the image forming 
15 device 600 can be configured with a Linux box chaiwood server that is configured to 

control the operation of the card reader 620, control the operation of the print request 
processing system 605, and also perform communications with network devices or 
other external devices instead of having the chai service 615. 

[0048] In one example, the chai service 615 can be a virtual machine configured 
20 to interpret and execute Java-like code. The chai service 615 can be configured to run 

chai servelets that perform desired functions associated with the processing of the 
print requests, as described, including the identification functions and/or charging 
functions. In another example, the Linux box chaiwood server 625 may be a 
computer or server connected to the image forming device 600 where the chaiwood 
25 server 625 is configured to receive print jobs and read identification card data and 

otherwise perform the functions of the print request processing system as described. 

[0049] Illustrated in Figure 7 is an example of a graphical user interface 700 that 
may be used with an image forming device or other computing device that processes 
print requests in a manner described above. For example, the graphical user interface 
30 700 can include logic configured to display inputted claim/owner data 705 which may 

include information read from an identification card/credit card that is read by an 
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input device. As previously described, a user may claim or otherwise retrieve print 
requests from an image forming device by entering owner data such as a credit card 
while in the vicinity of the image forming device. If the owner data (claim data) is 
matched with pending print requests, the logic can be configured to receive data 
representing the matched print requests that belong to a user. The claim data can 
include account information to allow an account to be charged for processing the one 
or more print requests claimed. The data from the matched print requests) 710 can 
be displayed by the graphical user interface 700. In this manner, a user attempting to 
claim print requests can see on a display what his/her inputted owner data was and 
also see a list of one or more print requests that belong to them and are being held for 
processing. One or more of the matched print requests 710 can then be selected by 
the user and printing can be initiated as well as automatically charging a user account 
for the printing services. 

[0050] Illustrated in Figure 8 is an example of a print driver 800 that is 
configured to operate on a client device that can generate print requests for an image 
forming device that delays print requests until claimed by an owner. For example, the 
print driver 800 can include logic configured to generate a print request 805 and 
obtain owner identification/charge data 810 from the user requesting a print job. The 
identification/charge data 810 can then be embedded with the print request 805 and 
transmitted to an image forming device. As previously described, the owner 
identification/charge data 810 can include the user's name, a credit card number or 
portion thereof, or other desired type of identification data that can be subsequently 
used to identify the owner of the print request, or combinations thereof. In one 
example, the data 810 can be placed stored as header information with the print 
request. The print request can then be transmitted to a selected image forming 
device. 

The print driver 800 can include logic to request identification information and/or 
billing information from a user and then inject or otherwise associate the 
identification information with the print request. This may be performed, for 
example, using a printer job language to embed attributes of the identification 
information. The identification attributes can be configured as meta data that is 
positioned in front of the print request data before it is sent to a printer. When 
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received by the printer, the processing system can extract the meta data and store the 
meta data for subsequent identification with a user wishing to claim a print request. If 
a received print request does not include the appropriate meta data, the print request 
can be discarded and/or segregated for special processing. A received print request 
that has the appropriate meta data or other configuration is then configured to be 
maintained in a pending state in the image forming device until physically claimed by 
the user by providing a claim data to the image forming device that matches the 
owner identification data 810. The claim data can include identification information 
to identify the print request and charging information to charge a user account for 
processing the print request. 

[0051] It will be appreciated that any of the described image forming devices, 
computing devices, logics, and print request processing systems can be configured to 
discard invalid print requests. For example, an invalid print request may be one that 
does not include owner identification/charge data, or a print request that includes data 
5 that cannot be recognized by the print request processing system. Invalid print 

requests may also be held separately for special identification and/or processing. 

[0052] The following is an example application and scenario where the presently 
described embodiments may be implemented and used. For example, a user wishes to 
print a document from a computer. The computer is connected to a printer that is in a 

10 public location such as a library or coffee shop. Before submitting the print request, 

the computer obtains identity information from the user such as a name and/or credit 
card information. The identity information is combined with the print request and 
submitted to a print server or to the printer where the print request is held in a pending 
state. The user then walks over to the print server or printer and swipes their credit 

1 5 card in order to claim and retrieve their print request. The data read from the credit 

card is used to identify the user's pending print request, charge the credit card for 
printing services, and the print request is processed into a printed document. By 
having the user physically present to retrieve their print request, it may reduce the 
chances that the printed document is stolen or viewed by unauthorized people. 

20 Additionally, by not printing a print request until physically claimed, the resources of 

the printer can be better controlled by not permitting unauthorized print requests to be 
processed and by ensuring that services will be paid for. 
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[0053] While example systems, methods, and so on have been illustrated by 
describing examples, and while the examples have been described in considerable 
detail, it is not the intention of the applicants to restrict or in any way limit the scope 
of the appended claims to such detail. It is, of course, not possible to describe every 
5 conceivable combination of components or methodologies for purposes of describing 

the systems, methods, and so on described herein. Additional advantages and 
modifications will readily appear to those skilled in the art. Therefore, the invention, 
in its broader aspects, is not limited to the specific details, the representative 
apparatus, and illustrative examples shown and described. Accordingly, departures 

10 may be made from such details without departing from the spirit or scope of the 

applicants' general inventive concept. Thus, this application is intended to embrace 
alterations, modifications, and variations that fall within the scope of the appended 
claims. Furthermore, the preceding description is not meant to limit the scope of the 
invention. Rather, the scope of the invention is to be determined by the appended 

1 5 claims and their equivalents. 

[0054] To the extent that the term "includes" or "including" is employed in the 
detailed description or the claims, it is intended to be inclusive in a manner similar to 
the term "comprising" as that term is interpreted when employed as a transitional 
word in a claim. Furthermore, to the extent that the term "or" is employed in the 
20 claims (e.g., A or B) it is intended to mean "A or B or both". When the applicants 

intend to indicate "only A or B but not both" then the term "only A or B but not both" 
will be employed. Thus, use of the term "or" herein is the inclusive, and not the 
exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. 
Ed. 1995). 
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